1. Technical Field
The invention is related to software development and engineering tools which increase software design productivity.
2. Background Art
A high fraction of the time spent developing new software systems is spent performing mundane functions that are well known in the art. By comparison, when a mechanic goes to make a new device, he does not reinvent mundane pieces, such as the threaded screw. The same cannot be said of software engineers. Software engineers have long identified the need for convenient, easy-to-learn, intuitive software reuse systems to support rapid prototyping.
Software development is a tedious, expensive, time-consuming, and error-prone process. Approaches to improving the process include object-oriented programming, computer-aided software (CASE), software reuse, formal mathematical verification, structured walkthroughs, formal testing regimens, and so on.
Most hardware artifacts are constructed from standard parts fitted together with standard fasteners. Custom parts and fasteners are used only when their much higher cost can be justified. Using standard parts not only makes replacement easier but also amortizes the cost of design, engineering, and tooling across large production runs, often spanning decades of time.
The analogy in software to the use of standard parts in hardware is the reuse of previously developed software code, modules, libraries, designs, architectures, documentation, test data, test routines, test strategies, and so on. All of these information artifacts, and more, are software in the sense that they are directly related to the production and use of computer instructions. We use the term "software" in this broad sense in this paper.
One reason software is expensive is that, for the most part, we do not amortize the cost or development by reusing components in new applications. Software is still, by and large, a craft process characterized by the custom design and fabrication or components. The lack of software reuse is especially ironic since economies of scale are easier to achieve in software than in hardware. The reason is that software is mere information and, therefore, massless. Replicating and distributing it is relatively inexpensive (a major cost driver in hardware industries is the mass of the objects being produced). One would think, on the face of it, that an industry that could achieve economies of scale relatively easily would eagerly do. Yet, we have not seen the "Software Industrial Revolution".
Many reasons have been advanced for the failure of the software industry to adopt a standard component parts technology. Perhaps the most plausible reason is that it often takes more effort merely to research existing software components than to develop them anew. In other words, many software developers-potential consumers of reusable software-simply find it more cost-effective to invent new software than to look for old software.
The only discipline in which software component reuse is traditional is computational mathematics. This is at least partly due to the fact that it requires a great deal of specialized knowledge and experience to write correct and efficient mathematical software. It is, in fact, for non-specialists, not easier to reinvent than to reuse. We find it interesting that the majority of mathematical software--the most reused software--is written in Fortran. Of all major programming languages, Fortran is perhaps the least hospitable, prima facie, to software reuse. It has virtually none of the packaging and information-hiding features that conventional wisdom deems helpful, if not necessary, for reusability. We take this fact as supporting evidence in favor of our consumer-side approach to software reuse, as opposed to a producer-side approach that posits basic changes in the way software is written as a precondition for reuse. People will reuse software, even if that software is not written for maximum reusability, if it is easier for them to reuse than to reinvent.
One prior attempt at making software retrievable is disclosed in U.S. Pat. No. 4,860,204 to Gendron et al. In this patent, software components called softrons are created in a single language and stored in a file cabinet metaphor, rather than using existing software components of any language. A particular softron is accessed in response to a user's selection of relevant software attributes. However, there is no disclosure of any means for permitting the user to first view the attributes and other characteristics of the accessed softron before incorporating it in a program under construction, absent external means of some sort. Gendron et al. therefore have nothing to do with attempting to reuse existing software, but rest their concept on creating a complete set of software components in a single language.